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SYSTEM AND METHOD FOR AUTOMATED AND CUSTOMIZABLE 
AGENT AVAILABILITY AND TASK ASSIGNMENT MANAGEMENT 

BACKGROUND 

5 Field of the Invention 

The invention relates to the field of customer service and the handling 
and processing of customer service requests. More specifically, the invention 
relates to handling and processing customer service requests received over a 
plurality of heterogeneous media. 

10 Background 

Customer service is an important part of any business. Many companies 
provide customer service via call centers in which incoming customer telephone 
calls are received and answered by customer service agents. Typically, each call 
center is staffed by agents with various skills. Calls are routed to an agent having 

15 an appropriate level of expertise for ha]"idling the particular kind of call. For 

example, an agent may have a language skill such as fluency in Spanish (in 
addition to English) or have expert knowledge of a particular product line. 

As the internet has expanded, many companies are taking advantage of 
this communications medium to provide added methods of customer service. 

20 Many companies receive customer requests and comments sent by email either 

directly or through a web site. Such companies employ customer service agents 
to respond to these email messages. Responses may be in the form of an email 
reply or a telephone call. 

In addition, the internet provides the ability to interactively service 

25 customers while the customer is accessing the company's web site. Such 

interactive customer service may take the form of interactive text, sometimes 
known as chat, or interactive voice over the internet. In the interactive voice 
scenario, a customer speaks into a microphone attached to the customer's 
computer while viewing the company's web site. The company must also 
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employ persons to handle such internet text and internet voice customer service 
requests. 

BRIEF SUMMARY OF THE INVENTION 

5 A system and method for blending tasks received from a plurality of 

media switches. The method comprises receiving a plurality of task data 
indicating a plurality of tasks and a plurality of agent data indicating a plurality of 
agents. The task data and the agent data are stored in a database system. Tasks are 
assigned to the agents according to workflows. The system comprises a blending 
10 engine coupled to a plurality of media switches and a plurality of agent 

workstations coupled to the blending engine. The blending engine receives a 
plurality of task data from the media switches. The agent workstations provide a 
plurality of agent data to the blending engine. The blending engine provides a 
plurality of task assignments to the agent workstations according to workflows. 

15 

BRIEF DESCRIPTION OF THE DRAWINGS 
Figure 1 illustrates a high-level schematic of the architecture of a blending 
system. 

Figure 2 illustrates the flow of actions taken by a blending system upon 
20 receiving an incoming task. 

Figures 3A and 3B illustrate a more detailed schematic of the architecture 
of a blending system. 

Figure 4 illustrates a more detailed the flow of actions taken by a blending 
system upon receiving an incoming task. 
25 Figure 5 illustrates the flow of actions taken by a blending system upon an 

agent becoming available. 
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DETAILED DESCRIPTION 

A. Overview 

The invention provides a system and method for handling and processing 
customer service requests received over a plurality of heterogeneous media. 
5 Customer service requests are referred to herein as tasks. Generally, the 

invention provides a system and method for blending tasks received from a 
variety of media. In one embodiment, the system and method of this invention 
provide for the blending of tasks for agents within a customer relationship 
center. These tasks may be voice calls, email notes, web interactions and any 

10 other interaction that can be handled electronically. In one embodiment, the 
blending method makes task routing decisions based on the contact center's 
workload across all media. While indiv^idual systems handle the specific media 
items, the blending method provides a single point of reference for work 
allocation decisions. 

15 B. A Blending System 

Figure 1 shows a high-level schematic of the architecture of a blending 
system. In one embodiment, the blend ing system includes media switches 10, a 
blending database 12, a blending engine 14, agent desktops 16, a workflow server 
18, and a customer database 20. The media switches include, but are not limited 

20 to, an automatic call distributor (ACD) 22, a web server 24 and an email server 26. 

Agent desktops may be, in one embodiment, computers such as desktop 
computers or, in another embodiment, networked terminals, and may, in either 
embodiment, be paired with a telephone or a phone implemented through 
software. 

25 Figure 2 shows the flow of actions taken by a blending system upon 

receiving an incoming task. A task is a customer contact item such as a voice 
call, email message, or web-collaboration request such as text chat or internet 
interactive voice. Tasks are received by a media switch dedicated to handling 
contacts in that particular medium. After a task is received by a media switch, as 

30 shown in block 30, the media switch attempts to route that task to an available 
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agent, as shown in block 32. If the media switch succeeds in finding an available 
agent, the agent, known as a non-blended agent, services the task, as shown in 
block 34. If the media switch cannot successfully assign the task, it sends task 
information to an adapter as shown in block 36, and the adapter forwards the 
5 task information to the blending engine?, as shown in block 38. The blending 

engine stores the task in the blending database, as shown in block 40, and 
executes a routing workflow in the woikflow server, as shown in block 42. 

The routing or "task queued" workflow executes business rules to 
determine whether a suitable agent is available to service the task, as shown in 

10 block 44. This decision may be based on information contained in a customer 

database as well as information in the blending database. In one embodiment, 
the business rules used to determine assignment and routing are built as part of 
the deployment of the system and are customizable. In one embodiment, these 
rules may, for example, involve finding the last agent that spoke to a particular 

15 customer and attempting to route the call to that agent. If that agent is 

unavailable, the skills of available agents could be assessed to establish which 
agent possesses the skills that most closely match the needed profile. The ethos of 
the blending system is to evaluate the current situation, and deliver to an agent 
the most appropriate task at that time. When a task is completed, the status of 

20 the system is re-evaluated and an "agent available" workflow is executed to 

determine which task is now most appropriate to assign to the available agent. 
In one embodiment, the blending database holds all the tasks across all the 
media, and, in this way, takes a "whole world" view of the workload of the 
system. In contrast, media switches only make decisions about their particular 

25 medium in isolation of the rest of the system. 

The decision of whether there is an agent available is passed to the 
blending engine from the workflow server. If no suitable agent is available, the 
task remains in the database as shown in block 46. If an agent is found to handle 
the task, the blending engine signals the agent's desktop application, which 

30 retrieves the task from the media switch, as shown in block 48. The agent 
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receives notification of the task assignment, as shown in block 50, and the 
blending engine determines whether the agent accepts the task, as shown in 
block 52. In one embodiment, the desktop application asks the agent to accept the 
task. In this embodiment, the agent may send a message to the blending engine 
5 via the desktop application declining the task. In one embodiment, the blending 

engine may time out if a task acceptance notification is not received in a specified 
period of time. If the agent accepts the task, the desktop application signals the 
blending engine that the agent accepted the task, as shown in block 54. In one 
embodiment, the blending engine does not respond to the media switch after 

10 receiving task data. The desktop application then requests the task from the 

appropriate media switch on behalf of the agent, as shown in block 58. The agent 
may then service the task, as shown in block 60. If when the agent receives the 
task assignment from the blending engine, the agent rejects the task, the desktop 
application signals the blending engine that the agent rejected the task 

15 assignment, as shown in block 56. 

In the situation where no available agent is found, the task remains in the 
database. When an agent via the desktop application signals that the agent is 
available to take more work, the blending engine causes a workflow to execute. 
In one embodiment, an "agent available" workflow uses the agent skill 

20 information stored in the blending database to determine the most appropriate 

task for the agent to take at the time. This decision is passed back to the agent 
desktop via the blending engine, and the desktop application retrieves the task 
from the media switch. 

In another embodiment, a "check system status" workflow may execute to 

25 monitor the status of the entire system. Execution of a "check system status" 

workflow may be event based or time based. That is, execution may be triggered 
upon the expiration of a defined period of time, such as, for example, every 
minute, and upon the occurrence of particular defined events, such as, for 
example, when a task is queued, or when a defined number of tasks are queued. 

30 In one embodiment, agents may have a status of "available if needed." In this 
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embodiment, the "check system status" workflow may call in agents when the 
system load exceeds a predetermined threshold by transitioning the status to 
"available" which causes the "agent available" workflow to run. In another 
embodiment, the "check system status" workflow interrupts agents, requesting 
5 that they abandon one task for another that has become more important. This 

embodiment is particularly effective for re-assigning agents handling email 
when call volumes suddenly rise. In this embodiment, the blending engine 
instructs agents to abandon their email tasks and switch to taking calls. In a 
related embodiment, the agent status miay be set to AVAILABLE, 

10 UNAVAILABLE, or AVAILABLE IF NEEDED. In such an embodiment, the 

"check system status" workflow may assign tasks to agents having the status of 
AVAILABLE IF NEEDED if certain criteria are met. This embodiment is 
particularly useful if persons with other positions in the company have the skills 
needed to assist in handling tasks when the volume of tasks exceeds a 

15 predetermined threshold. 

C. Blending System Architecture 
1. Overall Functionality 

Figures 3A and 3B illustrate a more detailed schematic of the architecture 
of a blending system. (Figures 3A and 3B combine to form one larger figure and 

20 should be considered together.) Blending engine 60 consists of four components: 

adapter manager 62, workflow broker 64, database manager 66, and agent 
manager 68. In one embodiment adapter manager 62 communicates with other 
components via adapter message handlers 90, and agent manager 68 
communicates with other components via agent message handlers 92. More 

25 specifically, adapter manager 62 provides common interface connectivity 

between media switches 70 and blending engine 60. Workflow broker 64 is a 
conduit for invoking and receiving responses from workflow server 65. 
Database manager 66 provides connectivity to blending database 72. In one 
embodiment, the blending database is comprised of dynamic database 76 and a 

30 static database 78. Agent manager 68 manages communication between blending 
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engine 60 and agent desktop 74. The media switches 70 communicate with the 
blending engine via adapters 82 specifically designed for each particular switch. 
Each adapter 82 places messages received from a particular media switch 70 into a 
new message in common message format to be forwarded to blending engine 60. 
5 The common message format used in one embodiment is extensible markup 
language, more commonly known as XML, ver. 1.0 (more information is 
available from the World Wide Web C!onsortium, Massachusetts Institute of 
Technology, Laboratory for Computer Science, 545 Technology Square, 
Cambridge, Massachusetts 02139). In one embodiment, the interface between 

10 adapters 82 and blending engine 60 is provided via adapter queues 88 that allows 

for asynchronous communication. In one embodiment, adapter queues 88 are 
implemented as Microsoft Message Queue (MSMQ). More information on 
MSMQ is available from Microsoft Corporation, Redmond, Washington. 

At least three messages are produced by each of adapters 82: task queued, 

15 task dequeued, and reset. More specifically, a "task queued" message is sent 

when a task needs to be assigned to an agent. A "task dequeued" message is sent 
when a task has been assigned to an agent, whether through blending or 
independently. In addition, a "task decjueued" message may be sent when the 
task has been abandoned such as, for example, when a caller hangs up. A "reset" 

20 message is sent to clear queues when an adapter is brought up and taken down. 

Other messages may be produced by adapters, including a "task queued" message. 

Adapter manager 62 determines the medium to which the received 
message is related and passes that message to the corresponding adapter message 
handler 90. There is a one-to-one correlation between each of adapters 82 and 

25 each of adapter message handlers 90. Adapter message handlers 90 extract 

information from the common message format message, and perform actions 
relevant to the particular message type. That is, if the message signals that a task 
has been queued, the appropriate adapter message handler 90 will request 
database manager 66 to store the task in the relevant virtual queue within 

30 dynamic database 76, and will then request workflow broker 64 to initiate a "task 
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queued" workflow. When a response is received from workflow server 65, 
workflow broker 64 passes the response to an adapter message handler 90. 

If an agent has been found to handle the task, adapter message handler 90 
informs the agent manager 68 via the agent message handler 92 to pass the task 
5 data to the relevant agent desktop 74. Agent manager 68 sends a common format 

message (in one embodiment, an XML message) to desktop helper 94 via agent 
queue 96 (in one embodiment, an MSMQ) from which the desktop application 98 
determines the medium and any other relevant information (such as call/email 
ID). Desktop helper 94 provides a communication layer between desktop 

10 application 98 and agent manager 68. In a similar way to the adapter helpers 83, 

desktop helper 94 manages agent queue; 96 while the desktop application 98 
creates and processes messages to be passed through agent queue 96. In addition, 
desktop helper 94 creates two messages: "connect" and "disconnect." The 
messages are passed into desktop helper 94 in a common message format, such 

15 as, in one embodiment, XML, and are forwarded to agent manager 68. Desktop 

application 98 uses the task data to select the correct media switch 70 with which 
to work and, via the relevant application program interface (API) 99, requests 
that the task be delivered to that agent. In one embodiment, when the desktop 
application is executed, connections to each of the media switches for which the 

20 agent is qualified are automatically established via the appropriate APIs. 

If an agent is not found, the task will remain in the database until such a 
time as the media switch assigns it to a non-blended agent, or a blended agent 
becomes available. In the latter scenario, desktop application 98 sends a common 
format message (in one embodiment, an XML message) to desktop helper 94 to 

25 indicate that the agent requires more work. Desktop helper 94 forwards this 

message to agent manager 68 via agent queue 96, which then passes the request 
to workflow broker 64 via agent message handler 92. The flow from this point is 
the same as for task queued. 
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2. Media Switches 

Media switches 70 receive, queue: and deliver its associated medium in 
electronic format. In addition, media switches generate events signaling that a 
task has been queued, de-queued and, in the case of real-time interactions, 
5 disconnected. A media switch provides an interface to enable a desktop 

application to request and be delivered a task. Some media switches allow for 
specific tasks to be requested, while other media switches only provide the oldest, 
or other switch-determined, task. Media switches may be smart or dumb. 
Examples of media switches 70 include, but are not limited to, ACD 70A (such as 

10 those available from Aspect Communications of San Jose, CaHfomia, Lucent 
Technologies of Murray Hill, New Jersey, and Nortel Networks Corporation, 
Brampton, Ontario, Canada) email server 70C (such as Aspect's Aspect Customer 
Email available from Aspect Communications of San Jose, California), and web 
server 70B (such as Web Interaction available from Aspect Communications of 

15 San Jose, California). 

ACD 70A provides access to incoming telephone calls from a public switch 
telephony network (PSTN) 75. Live telephone calls are queued, and information 
about the calls is then routed to blending engine 60 when a non-blended agent is 
unavailable to process the incoming caLl. In another embodiment, voice mail 

20 may be stored by ACD 70 A and then routed to blending engine 60 for processing. 

A POP3 mail server 84 may also be a media switch. POPS is short for Post 
Office Protocol, Version 3, an internet n\ail standard promulgated by and 
available from the Network Working Group of the Internet Engineering Task 
Force at http://www.ietf.org/rfc/rfcl939.txt. POPS servers support receiving, 

25 queuing and delivering messages in email format. Although, POPS servers do 

not have the capability to pro-actively notify an external system of the queued of 
an email message, in one embodiment, a POP3 adapter, effectively a wrapper 
application, is used to provide a simpk; polling mechanism to check the current 
state of the POPS queue, thus giving a POPS server full media switch capabilities. 
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In one embodiment, web interaction, text chat and voice over the internet 
capabilities are provided by web server 70B. Communication between an agent 
and a customer are provided by any method known to these skilled in the art to 
establish text chat and voice over internet connections. In such an embodiment, 
5 the customer's display may automatically mimic the sequences of internet web 

pages traversed by the agent. In such an embodiment, agent desktop 74 signals 
web server 70B via computer telephony integration (CTI) server 97 that a 
connection has been established, which is in turn picked up by CTI server 71. 
Web server adapter 82B, coupled to CTI server 71, translates establishment of a 
10 web server connection into a "dequeued" message and forwards the message to 
adapter manager 62 of blending engine 60 via adapter queue 88. Various other 
implementations are possible and readily known by those skilled in the art. 

In another embodiment, each media switch includes a private database for 
storing configuration data. In one embodiment, whenever a media switch 
15 updates its database, the media switch sends a message to the blending database 

via the adapter manager of the blending engine which then updates the 
configuration data. In a related embodiment, the blending database may 
regularly poll the media switch databases for updated or new configuration data. 
Configuration data may include information such as, for example, a group data 
20 specifying to which group an agent belongs. 
3. Adapters 

a. Adapter 

The role of the adapter is to provide connectivity to media switches. Each 
media switch 70 has a differing output in terms of the number of event messages 
25 it produces, and the format and content of those messages. To ensure that the 

blending engine 60 does not have to support multiple types of messages, adapters 
82 offers a common set of messages across the whole range of switches. That is, 
ACD adapter 82A receives ACD specific messages from ACD 70A via CTI server 
73 and processes them into common messages in a common message format; 
30 web server adapter 82B receives web server specific messages from web server 
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70B via CTI server 71 and processes them into common messages in a common 
message format; and email adapter 82C] receives email specific messages from 
email server 70C via email queue 85 and processes them into common messages 
in a common message format. 
5 In one embodiment, at least three common messages are supported: "task 

queued", "task dequeued" and "reset". A "task queued" message is sent when a 
task needs to be assigned to an agent. A "task queued" message causes the 
blending engine to add the task to the appropriate queue in the blending database 
and to invoke the "task queued" workflow to determine if an appropriate agent 

10 is available to service the task. A "task dequeued" message is sent when a task 

has been assigned to an agent. A "task dequeued" message causes the blending 
engine to remove the task from the appropriate queue in the blending database. 
A "reset" message is sent when an adapter has been brought up or taken down. 
The "reset" message causes the blending engine to empty the particular adapter 

15 queue 88 for the particular media switch. 

Although these kinds of messages are common across adapters, in one 
embodiment, each message is named differently for each adapter so that the 
messages from different media switches are easily and instantly distinguishable 
and may be processed by the blending engine based on their name. In addition, 

20 even though the same kinds of messages may be used, the content of the same 
kind of message may vary for each adapter, even if the adapter is of the same 
type of adapter. For example, a task queued message from an Aspect ACD 
contain different information and different fields than a task queued message 
from a Lucent ACD. 

25 In one embodiment, these common kinds of messages are formatted and 

transferred in a common message format such as XML. This offers the 
advantage that the blending engine has only one message format to process, 
while the actual structure and content of the messages is not restricted using a 
common message format also facilitates support for new and additional switches. 

30 Each media switch has different data pertinent to its particular medium. For 
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example, dialed number identification service (DNIS) and automatic number 
identification (ANI) services that provide the telephone number of a call, are 
important to a voice telephone call, but are not available or relevant to an email 
message; whereas email messages have to/from addresses and a subject line not 
5 available for voice telephone calls. 

Although the internal format of the messages are different for each media 
switch, in one embodiment, the messages are all sent via XML. The adapter for a 
media switch takes the information produced by that switch and bundles it into a 
common message format, in one embodiment, XML message. The messages 
10 contain data items expected by the corresponding adapter message handlers 90 for 

the media switch. The common message format serves effectively as a protocol 
between the adapters 82 and the adapte;r message handlers 90. When support for 
a new media switch is required, a new adapter that produces common messages 
in the common message format must be created. The following is an example 
15 "call queued" message from an ACD adapter in XML format: 

<?xml version="1.0" ?> 
<START> 

<TYPE> 

ASPT_CALL_ARR 
20 </TYPE> 

<CUSTOM> 

<MEDIA_ID TYPE ="INT"> 
5 

</MEDIA_ID> 

25 <TASK_ID TYPE ="INT"> 

1029 
</TASK_ID> 

<APPLICATION_ID TYPE ="INT"> 
126 

30 </APPLICATION_ID> 
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<TRACK_NUM TYPE = "INT"> 

10529 
</TRACK_NUM> 
<DNIS TYPE="STRING"> 
5 18003254958 
</DNIS> 

<ANI TYPE="STRING"> 

4082651093 
</ANI> 

10 <STATUS TYPE="STRING"> 

ARRIVED 
</STATUS> 

<STATUS_CHANGE TYPE="TIMESTA]V[P"> 
1999-07-27 10:23:56.000100 
15 </STATUS_CHANGE> 
</CUSTOM> 
</START> 



Adapter message handler 90 receives and parses this message, interrogates 
20 the value of TYPE, and then coordinates the processing required by that type of 

message. In this example, this includes instructing database manager 66 to add 
this information to blending database 72. Other messages, such as "call queued", 
may, in one embodiment, cause workflow broker 64 to sennd a message via 
workflow queue 67 to workflow server 65 which causes a workflow to execute. 
25 In another embodiment, a "call queued" or other message may cause adapter 

message handler 90 to instruct workflow broker 64 to send a "user defined event" 
to workflow server 65. 

In one embodiment, when using XML the order in which the data items 
(contained in the <CUSTOM> ... </CUSTOM> tags) are positioned is 
30 unimportant. In this embodiment, if a data item is non-mandatory, it does not 
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need to appear at all. That is, the data item does not require a placeholder. The 
message contains information signaling that an event has occurred creating a 
task; the message does not contain the actual task itself. This is obvious for voice 
calls, but not so for email or other text-based media. The messages contain 
5 information about the task needed to make decisions about retrieving and 
processing the task. 

b. Adapters and Adapter Helpers 
A key role of adapters 82 is to trcinslate native messages from the media 
switches into a common message format such as, in one embodiment, XML. 

10 Although there is a common message format, what is common about the format 

is the general structure and arrangement of the message. The internal 
information within each common message format message remains media 
specific. In one embodiment, the adapters 82 communicate with the adapter 
manager 62 via the relevant adapter queue 88. Whereas each adapter 82 is 

15 specific to each media switch 70, the communication between adapters 82 and the 

adapter manager 62 is generic. The adapter helpers 83 assist the adapter 82 by 
establishing a connection to adapter manager 62 on startup, closing the 
connection on shutdown, and managing messages on the adapter queues 88. 
4. Blending Engine 

20 a. Adapter Manager 

Adapter manager 62 acts as the communication hub between adapters 82 
and adapter message handlers 90. In oi\e embodiment, when an adapter 82 has a 
message for the blending engine 60, the adapter places the message in a common 
message format. In one embodiment, to achieve this, adapter 82 wraps the 

25 message in XML and places it in an adapter queue 88. In one embodiment, a 

mandatory field in the common message format and, in one embodiment, in the 
XML message, is TYPE. This field allows the adapter manager 62 to determine to 
which adapter message handler 90 the message should be sent. 
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b. Adapter Message Handlers 

The role of the adapter message handlers 90 is to extract the information 
sent by an adapter and act upon that information within the blending engine on 
the adapter's behalf. In one embodiment, there is one adapter message handler 
5 for each media switch. The adapter m(?ssage handlers 90 serve three purposes. 
The adapter message handlers 90: (1) Iceep task information in the blending 
database 72 current; (2) invoke "task queued" workflows; and (3) request agent 
manager 68 to assign tasks to agents. JvLessages are passed to the adapter message 
handlers 90 via adapter manager 62 in blending engine 60. When the adapter 
10 message handlers 90 start up, each adapter message handler registers with the 

adapter manager 62 and specifies which kind of messages it processes. This 
registration allows for matching those messages produced by the corresponding 
adapter 82 to the appropriate adapter message handler 90. 

c. Workflow Broker 

15 Workflow broker 64 receives common message format messages from the 

adapter message handlers 90 to process "task queued" events. Workflow broker 
64 receives common message format messages from agent message handler 92 to 
execute "agent available" workflow functionality. The content of these messages 
determines what event and parameters workflow broker 64 sends to workflow 

20 server 65 to cause the correct workflow to execute. In one embodiment, 

workflow broker 64 communicates with workflow server 65 via workflow queue 
67. Communicating through a queue avoids dropped connections at high 
throughput. In one embodiment, workflow queue 67 is an MSMQ. In this 
embodiment, workflow broker 64 uses a Component Object Model Intelligent 

25 Route Administrator (COMIRA) component 108 to manage this communication. 

This is based on the Component Object Model (COM) standard popularized by 
Microsoft Corporation of Redmond, V\/^ashington. 

d. Database Manager 

Database manager 66 provides Open Data Base Connectivity (ODBC) 
30 communication between blending engine 60 and blending database 72. ODBC is 
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a Standard database access method popularized by Microsoft Corporation of 
Redmond, Washington. ODBC uses Structured Query Language (SQL) as its 
database access language . In one embodiment, database manager 66 does not 
provide access to external databases, such as a customer database. In one 
5 embodiment, database manager 66 receives common message format messages 

from adapter message handlers 90 and the agent message handler 92. In some 
embodiments, these message are formatted as XML messages. In such an 
embodiment, these messages contain structured data informing database 
manager 66 which database, object and attributes need to be added to, updated or 

10 deleted from blending database 72. For example, a "call queued" message 

received by the ACD message handler 90 by the adapter manager 62 via an 
adapter queue 88 is bundled as an XML message and is sent to and informs the 
database manager 66 how to store that information in blending database 72. In 
this embodiment, the common message format XML message sent from the 

15 message handler to database manager 66 is: 



<?xml version="1.0" ?> 



<START> 



<TYPE> 



ASPT_CALL_ARR 



20 



</TYPE> 



<HEADER> 



<STORAGE> 



DYNAMIC 



</STORAGE> 



25 



<OBJECT> 



T_ASPT_CALL 



</OBJECT> 



<OPERATION> 



ADD 



30 



</OPERATIC)N> 



16 



</HEADER> 
<DATA> 

<T_ASPT_CALL> 

<MED[A_ID TYPE ="INT"> 
5 

</MEDIA_ID> 
<TASK_ID TYPE ='TNT"> 

1029 
</TASK_ID> 

<APPIICATION_ID TYPE ='TNT"> 
126 

< / APPLIC ATION_ID> 
<TRA(:K_NUM TYPE ="INT"> 

10529 
</TRACK_NUM> 
<DNIS TYPE="STRING"> 

18003254958 
</DN]S> 

<ANI TYPE="STRING"> 

4082651093 
</ANI> 

<STATUS TYPE="STRING"> 

ARRIVED 
</STATUS> 

<STATUS_CHANGE TYPE="TIMESTAMP"> 

1999-07-27 10:23:56.000100 
</STATUS_CHANGE> 
</T_ASPT_CALL> 
</DATA> 
</START> 

17 



002950.P053 

This XML message instructs database manager 66 to add data to the 
T_ASPT_CALL table in dynamic database 76. The data itself is held in the 
<DATA> ... </DATA> tag pairing. Database manager 66 parses this data, 
5 constructs the correct SQL statement to perform the action, and sends it to 

dynamic database 76 via ODBC. 

e. Agent Manager 
At startup, desktop helper 94 communicates with agent manager 68 to 
specify which queue the agent manager should use to send messages to that 
10 particular agent desktop. In one embodiment, the agent's ID is used as part of the 

queue name. In this way, agent manager 68 is able to distinguish between, and 
deliver tasks to the appropriate agent queue 96 and thus to the appropriate 
individual agent desktops 74. Like the communication between adapters 82 and 
adapter manager 62, there is one queue, agent queue 96, dynamically allocated for 
15 sending messages between agent manager 68 and each of the desktop helpers in a 

plurality of agent desktops (although only one agent queue 96 and one agent 
desktop 74 with one desktop helper 94 are depicted). 
5. Blending Database 

Blending database 72 holds configuration information about agents and 
20 media switches, and a copy of the queues for all media switches. The blending 
database is accessed by the various workflows to accomplish task and agent 
assignments. In one embodiment, the blending database comprises two 
databases, dynamic database 76 and staiic database 78. In one embodiment, the 
d5mamic, in-memory database is a SQL database such as the TimesTen'^'^ database 
25 system available from TimesTen Performance Software, Inc., 2085 Landings 

Drive, Mountain View, California 94043. Dynamic database 76 is a real-time in- 
memory database containing a virtual model of the queues on media switches 
70. Blending database 72 also contains configuration information for speed of 
access. Using a dynamic, in-memory database as part of the blending database 
30 allows for fast access to information. In one embodiment, persistent information 
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such as agent and media configuration is stored in static database 78. In one 
embodiment, static database 78 is a wri1:eable media database such as OracleSi 
available from Oracle Corporation, 500 Oracle Parkway, Redwood Shores, 
California 94065. This static, writeable media database is used in conjunction 
5 with the dynamic, in-memory database to prevent data loss when a machine 

crashes. 

Dynamic database 76 is, in one embodiment, an in-memory relational 
database management system (RDBMS) that is accessible through SQL via ODBC. 
The dynamic RDBMS has advantages over static RDBMS systems in that 
10 optimization algorithms can be more precise since they do not need to account 

for disk access. In addition, delays incurred while data is accessed from physical 
disks are eliminated when using a dynamic RDBMS. The dynamic, in-memory 
RDBMS is, therefore, significantly faster than traditional static RDBMS 
technologies. 

15 Blending database 72 contains a number of standard entries. These entries 

may reflect, in various embodiments, multiple skill classifications of agents 
which are used by the workflows to assign tasks to agents. These entries may be, 
maintained by an admin client 112 that communicates with blending database 72 
via database manager 66. If additional information is required to be stored in 

20 blending database 72, this additional information may be added according 

methods known to those skilled in the art. For example, a "first language" 
property may be added to media blending agent details. In this way, admin client 
112 may be used to maintain blending database 72. 

In one embodiment, an historical database is also used. Historical 

25 database 84 effectively listens in on what is occurring in the blending engine 60 

via feed control 87. In one embodiment, feed control 87 receives information 
from all components of the blending system. For clarity, input to feed control 87 
from adapter manager 62, workflow broker 64, database manager 68, agent 
manager 68, adapter message handlers 90 and agent message handlers 92 are not 

30 depicted. Historical database 84 is cou]:)led to feed control 87 via historical 
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database queue 86. In one embodiment, historical database queue 86 may be an 
MSMQ. Historical database 84 receives XML formatted messages and may 
maintain historical information gathereid from messages sent within the 
blending system. The admin client 112 may use the historical information to 
5 prepare useful information, such as, for example, how long it takes agents in 

general to handle particular kinds of tasks, how long it takes agents a particular 
agent to handle particular kinds of tasks, and which agents worked with 
particular client companies or particular persons in servicing prior tasks. Such 
information is useful to a customer service center administrator in developing 
10 customer service policies for agents to follow and managing employee agents. 

6. Executive Service 

The executive service 114 starts up and gracefully shuts down the blending 
engine components. When the executive service starts up, it enumerates all the 
managers and helpers, allowing the handlers to register with the managers, and 
15 the managers to register with each other. 

D. Workflows 

Workflows implement various business rules which vary depending on 
the particular embodiment and implementation. In one embodiment, 
workflows work to allocate agents and tasks from all media switches. In another 

20 embodiment, workflows only allocate tasks received over one kind of media 

switch. In one embodiment, the business rules invoked by the blending engine 
handle two scenarios: (1) finding an available agent to deal with an incoming 
task, processed by the "task queued" workflow; and (2) finding a queued task for 
an agent becoming available and requesting more work, processed by the "agent 

25 available" workflow. The latter is more likely to result in a successful 

assignment as it is far more common in contact centers for tasks to be queuing, 
waiting for an agent to become available, than for agents to be waiting for long 
periods of time for work to arrive. In one embodiment, a "check system status" 
workflow is also provided to periodically execute and achieve agent assignments 

30 or re-assignments when certain system conditions exist, such as if the system 
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volume is beyond a certain predetermined threshold. Workflow client 77 
provides access to the blending system such that a system manager may amend 
existing workflows such as for customization. In addition, the workflow client 
allows for and provides an extensive system for adding new workflows beyond 
5 those discussed herein. 

1. Task Queued Workflow 

Figure 4 illustrates a more detailed the flow of actions taken by a blending 
system upon receiving an incoming task. Whenever a task is queued on a media 
switch, as shown in block 160, the media switch converts the task information 

10 into a common message format the bleading engine can process, as shown in 

block 162. The media switch signals the blending engine that a task needs to be 
processed by forwarding the task, represented as task information in a common 
message format, to the blending engine, as shown in block 164. In one 
embodiment, the blending engine maintains a set of queues in the blending 

15 database, one for each media switch. In this way, the blending database 

maintains a snapshot of the workload of the media switches of the contact center. 
Using this snapshot, combined with agent availability data and agent skill data of 
the agents, workflows determine the most suitable agent for the task at the 
particular moment in time. When a task is queued on a media switch, it is 

20 added to the blending database with a status of AVAILABLE, as shown in block 

166. A workflow is then executed to determine whether a suitable agent is 
available to service the task, as shown in block 168. 

The emphasis in "task queued" workflows is finding agents that are 
available to handle the task. In one embodiment, if multiple agents are 

25 available, the task is routed to the agent that has waited longest since their 

previous task. In another embodiment, assignment of tasks is based on that 
agent's relative skill in a particular me(iium. For example, in such an 
embodiment, if an email message is to be serviced, the email message is routed 
to the agent with the highest email-handling skill level. In yet another 

30 embodiment, a task is routed based on consideration of the business area to 
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which the contact relates so that the agent with the highest skill in that business 
area is assigned the task. The criteria and rules for these decisions are dependent 
on the information available to the workflow. In various embodiments, the 
blending database maintains pertinent data about each agent that may be 
5 important in determining which agent should be assigned a particular task. In 

these embodiments, the business rules may contemplate the following: the 
agent's fluency in a language that may be required to service the task is 
considered, the number of hours the agent has been at work without a break, the 
agent's expertise in a product area, the agent's proficiency in using particular 

10 kinds of media, etc. 

In one embodiment, the business rules of workflows may be customizable 
and exist in multiple varying embodiments. Workflows can be very complex, 
with decisions being made based on many different sources of information. For 
example, in one embodiment, workflovi^s interrogate a customer database in 

15 addition to the blending database to determine whether the caller is a high- 

value, VIP customer, or a less important customer, and route the call 
accordingly. In another example, another embodiment provides for workflows 
communicating with older systems, known as legacy systems, to obtain 
information based on the business rules built into the older system. In such an 

20 embodiment, the investment already made in building the older business rules 

is not lost, and the business rules are not duplicated in a newly added 
component. Any of the workflow server's capabilities can be leveraged in this 
way to provide highly complex decision-making. 

In yet another embodiment, to allow for workflows to be run at high- 

25 volumes, one for each task queued, where intricate workflows include complex 

database queries, slow networking links and large data sets, throughput is 
increased and latency is reduced by database caching and/or database replication, 
i.e., redundancy or multiple copies of the same database on multiple computers. 
In one embodiment, when a task is decjueued or terminated, it is removed from 

30 the blending database, but no workflows is invoked. In another embodiment, 
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when a task is dequeued or terminated, an appropriate workflow such as, for 
example, a "task dequeued" workflow may be executed. 

Using the above and other criteria, the workflow determines if a suitable 
agent is available to service the task, as shown in block 168. The workflow server 
5 then advises the blending engine of its decision as to which, if any, suitable agent 

is available to service the task, as shown in block 170. If a suitable agent is not 
available, the task remains in the blending database, with status AVAILABLE, as 
shown in blocks 170 and 172. The task is later assigned either when an agent 
requests more work, if the media switch assigns the task to a non-blended agent, 

10 or if another custom workflow assigns the task, such as when a certain condition 

(like call volume exceeding a defined threshold) exists. If a suitable agent is 
available, the blending engine sends the details of that task to the agent's 
desktop, as shown in blocks 170 and 174. In one embodiment, not shown, the 
desktop application receives the task information and determines whether the 

15 agent accepts the task. In this embodiment, the action in blocks 52, 54, 58 and 46 

of Figure 2 may be executed. In this embodiment, if a suitable agent is available 
that accepts the task, the desktop application uses information about the task to 
determine what media switch and /or raedium corresponds to the task, as shown 
in block 175. The relevant API is then used to request the task from the 

20 particular media switch, as shown in block 176. While this process is carried out, 

the agent's blending status is set to RESERVED to signal to other workflows that 
the agent is not available to be assigned tasks. 

There is a possibility that the task being requested may no longer be 
queued when the desktop application requests it. This may occur, for example, 

25 when the media switch assigns the task to a non-blended agent, or, in the case of 

voice calls, when the caller hangs up. Cienerally, this scenario is catered for by 
dequeued / terminated messages being sent by the media switch which causes 
the blending engine to remove the task from the blending queue. However, the 
possibility that the sequencing of events may lead to a task being requested when 

30 the task is no longer available means that the desktop must be able to handle this 
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scenario. At this point, the desktop apphcation must determine whether the task 
has been received, as shown in block 178, by, in one embodiment, timing out, or, 
in another embodiment, processing a task not available notification. If the task 
an agent was assigned no longer exists, the desktop application requests another 
5 task, in one embodiment, by setting the agent status to AVAILABLE as shown in 

block 180. 

If the task is received by the desktop application, as shown in block 178, the 
desktop application will inform the agent manager via the desktop helper that 
this has occurred, as shown in block 182. In addition, the agent message handler 

10 will instruct the database manager to update the agent's status to 

UNAVAILABLE, as shown in block 184. The media switch also generates a "task 
dequeued" message at this point, causing that task to be removed from the 
blending database, as shown in blocks 186 and 188. 

In yet another embodiment, the "task queued" workflow may assign tasks 

15 to electronic devices via software agents in addition to human agents. In such an 

embodiment, automatic email, and /or automatic voice generation or play back 
may provide information requested by bhe task. For example, the task may be an 
email or telephonic request for a current balance or information about the last 
three transactions or last three checks ttiat cleared. Such information can easily 

20 automatically be retrieved and provided via email or text to voice synthesis via 

telephone. Similarly, driving directions to a facility or store policies may be pre- 
recorded in text or voice and automatically be sent as email or played back via a 
telephone. 

2. Agent Available Workflow 

25 Figure 5 illustrates the flow of actions taken by a blending system upon an 

agent becoming available. An "agent a vailable" workflow is invoked when an 
agent finishes handling a task and indicates that the agent is ready for another 
task. In one embodiment, a notification that an agent is ready for another task is 
agent-initiated. In this embodiment, the agent presses a button on a desktop 

30 application to indicate that the agent is ready for another task, causing a message 
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Stating that the agent is available to be sent to the blending engine, as shown in 
block 200. In another embodiment, a notification that an agent is ready for 
another task is automatic. In this embodiment, when the agent finishes with a 
task, the application used to carry out that task recognizes that the task has been 
5 completed, and communicates with the blending engine, sending a message that 

the agent is available to service another task, as shown in block 202. In one 
embodiment, changing the agent's status from "available if needed" to 
"available" triggers a communication to the blending engine that the agent is 
available to service a task. 

10 After receipt of an agent available message, as shown in block 204, the 

blending engine sends a message to the blending database placing the agent in a 
state of RESERVED, as shown in block 206, and the blending engine then 
invokes the agent available workflow by messaging the workflow server, as 
shown in block 208. The agent is put in a state of RESERVED in order to avoid 

15 the situation where a separate "task queued" workflow selects that agent for its 

task while the workflow is executing attempting to find the agent a new task. 
The workflow server then proceeds to find a task suitable for the agent by 
querying the blending database. If no suitable pending task is found, the agent 
state will be set to AVAILABLE, as shown in blocks 210 and 212. 

20 If a pending task is found for the agent, the blending database entry for the 

task is marked as RESERVED, as showrt in blocks 210 and 214. The blending 
database entry for the task is marked as RESERVED in order that another "agent 
available" workflow does not assign the task to another agent. The blending 
engine then sends information about the task to the agent, as shown in block 216. 

25 The desktop application uses the task information received from the blending 

engine to retrieve the task by extracting the task medium from the task 
information, as shown in block 218. Ttte agent then requests the task from the 
corresponding media switch, as shown in block 220. If the task no longer exists, 
the desktop agent requests another task,, as shown in blocks 222 and 224. If the 

30 desktop component succeeds in retrieving the task from the media switch, as 
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shown in block 222, the agent manager component of the blending engine is 
informed that the task has been successfully assigned, as shown in block 226, and 
the agent message handler informs the database manager to update the agent's 
status to UNAVAILABLE, as shown in block 228. As discussed above, the 
5 removal of the task from the media switch causes a "task dequeued" message to 
be generated by the media switch and sent to the blending engine, as shown in 
block 230. This message causes the task to be removed from the blending 
database. 

In another embodiment, when an agent requests more work, the agent 
10 may request that a particular medium be excluded. This embodiment is referred 

to as the empowered agent embodiment. For example, in this embodiment, an 
the agent may set certain parameters specify that, despite call levels being high, 
the agent will not accept any calls, preferring to deal with email messages 
exclusively. 

15 In the foregoing specification, the invention has been described with 

reference to specific embodiments thereof. It will, however, be evident that 
various modifications and changes can be made thereto without departing from 
the broader spirit and scope of the invention as set forth in the appended claims. 
The specification and drawings are, accordingly, to be regarded in an illustrative 

20 rather than a restrictive sense. Therefore, the scope of the invention should be 

limited only by the appended claims. 
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C LAIMS 

What is claimed is: 



1 1. A method comprising: 

2 receiving a plurality of task data indicating a plurality of tasks and a 

3 plurality of agent data indicating a plurality of agents; 

4 storing the task data and the agent data in a database system; and 

5 assigning respective tasks of the plurality of tasks to at least one of the 

6 agents according to workflows. 

1 2. The method of Claim 1 wherein the receiving comprises: 

2 receiving the task data from a plurality of sources. 

1 3. The method of Claim 2 wherein the plurality of sources comprise 

2 heterogeneous media switches. 

1 4. The method of Claim 3 wherein each of the heterogeneous media 

2 switches is from a group consisting of electronic mail systems, internet live text 

3 systems, internet voice transmission systems, telephonic voice systems, 

4 telephonic facsimile systems, and voice mail systems. 

1 5. The method of Claim 1 w]"ierein the receiving of the plurality of 

2 agent data comprises: 

3 receiving status messages from the plurality of agents. 

1 6. The method of Claim 5 wherein the status messages designate 

2 either busy or available. 

1 7. The method of Claim 5 wherein the status messages provide an 

2 agent availability data. 
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1 8. The method of Claim 7 wbierein the agent availability data 

2 comprises any one of the group including whether the agent is busy, is available, 

3 accepts a first type of task, declines a second type of task, multi-tasks, or accepts a 

4 task upon a system overloaded condition. 

1 9. The method of Claim 8 wherein the system overloaded condition is 

2 workflow defined. 

1 10. The method of Claim 1 wherein the database system comprises: 

2 at least one volatile memory database and at least one writeable medium 

3 database. 

1 11. The method of Claim 10 wherein the volatile memory database and 

2 the writeable medium database are synchronized. 
3 

1 12. The method of Claim 1 wherein the workflows are user definable. 

1 13. The method of Claim 1 wherein the assigning comprises: 

2 executing a task queued work flow responsive to receiving the task data; 

3 and 

4 executing an agent availability v/orkflow responsive to receiving the agent 

5 data. 

1 14. The method of Claim 13 wherein the executing of the task queued 

2 work flow comprises: 

3 storing the task data as a task entry in the database system; 

4 identifying a first agent of the plurality of agents to handle a first task of 

5 the plurality of tasks; and 

6 assigning the first agent the first task. 
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1 15. The method of Claim 14 wherein the identifying comprises: 

2 searching the database system foi" an agent entry meeting defined criteria. 

1 16. The method of Claim 15 wherein the assigning comprises: 

2 notifying the first agent to handle the first task; and 

3 receiving a response from the first agent either accepting or declining the 

4 first task; and 

5 if the first agent accepts the first task, updating the database system. 

1 17. The method of Claim 16 wherein the updating of the database 

2 system comprises: 

3 modifying the task entry and the agent entry. 

1 18. The method of Claim 13 wherein the executing of the agent 

2 availability workflow comprises: 

3 storing the agent data as an agent entry in the database system; 

4 identifying a first task of the plurality of tasks to be handled by a first agent 

5 of the plurality of agents; and 

6 assigning the first task to the first agent. 

1 19. The method of Claim 18 wherein the identifying comprises: 

2 searching the database system for a task entry meeting defined criteria. 

1 20. The method of Claim 19 wherein the assigning comprises: 

2 notifying the first agent to handler the first task; and 

3 receiving a response from the first agent either accepting or declining the 

4 first task; and 

5 if the first agent accepts the first task, updating the database system. 
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1 21. The method of Claim 20 wherein the updating the database system 

2 comprises: 

3 modifying the task entry and the agent entry. 

1 22. A system comprising: 

2 a blending engine coupled to a plurality of media switches such that the 

3 blending engine receives a plurality of task data from the plurality of media 

4 switches; 

5 a plurality of agent workstations coupled to the blending engine such that 

6 the agent workstations provide a plurality of agent data to the blending engine, 

7 and the blending engine provides a plurality of task assignments to the agent 

8 workstations. 

1 23. The system of Claim 22 further comprising: 

2 a blending database coupled to the blending engine such that the blending 

3 engine and the blending database exchange the agent data and the task data; and 

4 a workflow manager coupled to the blending database and the blending 

5 engine such that the workflow manager: 

6 accesses the blending database, 

7 executes workflows, and 

8 communicates the task assignments to the blending engine. 

1 24. The system of Claim 23 wherein: 

2 each media switch comprises an adapter coupled to a media specific queue; 

3 and 

4 each media specific queue is coupled to the blending engine. 

1 25. The system of Claim 23 wherein: 

2 each media switch provides at least one connection to one of a group 

3 comprising an electronic mail system, an internet live text system, an internet 
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4 voice transmission system, a telephonic voice system, a telephonic facsimile 

5 system, and a voice mail system. 

1 26. The system of Claim 23 wherein: 

2 each agent workstation comprises a desktop helper; and 

3 each desktop helper is coupled to the blending engine via a blending 

4 engine queue. 

1 27. The system of Claim 23 wherein the blending database comprises at 

2 least one volatile memory database synchronized with at least one writeable 

3 medium database. 

1 28. The system of Claim 27 wherein the blending database stores a 

2 plurality of task entries and a plurality of agent entries. 

1 29. The system of Claim 28 wherein the volatile memory database is a 

2 superset of the writeable medium database. 

1 30. The system of Claim 28 wherein the volatile memory database 

2 stores a blending engine queue data and a plurality of media specific queue data. 

1 31. The system of Claim 28 wherein the accesses the blending database 

2 comprises: 

3 reading the task entries and the agent entries. 

1 32. A machine readable medium having stored thereon instructions 

2 which when executed by a processor cause the machine to perform operations 

3 comprising: 

4 receiving a plurality of task data indicating a plurality of tasks and a 

5 plurality of agent data indicating a plurality of agents; 
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6 Storing the task data and the agent data in a database system; and 

7 assigning respective tasks of the plurality of tasks to at least one of the 

8 agents according to workflows. 

1 33. The machine readable medium of Claim 32 wherein receiving 

2 comprises: 

3 receiving the task data from a plurality of sources. 

1 34. The machine readable medium of Claim 33 wherein the plurality of 

2 sources comprise heterogeneous media switches. 

1 35. The machine readable medium of Claim 34 wherein each of the 

2 heterogeneous media switches is from a group consisting of electronic mail 

3 systems, internet live text systems, internet voice transmission systems, 

4 telephonic voice systems, telephonic facsimile systems, and voice mail systems. 

1 36. The machine readable medium of Claim 32 wherein the receiving a 

2 plurality of agent data comprises: 

3 receiving status messages from the plurality of agents. 

1 37. The machine readable medium of Claim 36 wherein the status 

2 messages designate either busy or available. 

1 38. The machine readable medium of Claim 36 wherein the status 

2 messages provide an agent availability data. 

1 39. The machine readable medium of Claim 38 wherein the agent 

2 availability data comprises any one of the group including whether the agent is 

3 busy, available, accepts a first type of task, declines a second type of task, multi- 

4 tasks, or accepts a task upon a system overloaded condition. 
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1 40. The machine readable medium of Claim 39 wherein the system 

2 overloaded condition is workflow defined. 

1 41. The machine readable medium of Claim 32 wherein the database 

2 system comprises: 

3 at least one volatile memory database and at least one writeable medium 

4 database. 

1 42. The machine readable medium of Claim 41 wherein the volatile 

2 memory database and the writeable medium database are synchronized. 

1 43. The machine readable medium of Claim 42 wherein the workflows 

2 are user definable. 

1 44. The machine readable medium of Claim 42 wherein the assigning 

2 comprises: 

3 executing a task queued work flow responsive to receiving the task data; 

4 and 

5 executing an agent availability workflow responsive to receiving the agent 

6 data. 

1 45. The machine readable medium of Claim 44 wherein the executing a 

2 task queued work flow comprises: 

3 storing the task data as a task entry in the database system; 

4 identifying a first agent of the agents to handle a first task of the plurality 

5 of tasks; and 

6 assigning the first agent the first task. 

1 46. The machine readable medium of Claim 45 wherein the identifying 

2 comprises: 
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3 searching the database system for an agent entry meeting defined criteria. 

1 47. The machine readable medium of Claim 46 wherein the assigning 

2 comprises: 

3 notifying the first agent to handle the first task; and 

4 receiving a response from the first agent either accepting or declining the 

5 first task; and 

6 if the first agent accepts the first task, updating the database system. 

1 48. The machine readable medium of Claim 47 wherein the updating 

2 the database system comprises: 

3 modifying the task entry and the agent entry. 

1 49. The machine readable medium of Claim 44 wherein the executing 

2 an agent availability workflow comprises: 

3 storing the agent data as an agent entry in the database system; 

4 identifying a first task of the plurality of tasks to be handled by a first agent 

5 of the plurality of agents; 

6 assigning the first task to the first agent. 

1 50. The machine readable me(iium of Claim 49 wherein the identifying 

2 comprises: 

3 searching the database system fo]- a task entry meeting defined criteria. 

1 51. The machine readable medium of Claim 50 wherein the assigning 

2 comprises: 

3 notifying the first agent to handle the first task; and 

4 receiving a response from the first agent either accepting or declining the 

5 first task; and 

6 if the first agent accepts the first task, updating the database system. 
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1 52. The machine readable meciium of Claim 51 wherein the updating 

2 the database system comprises: 

3 modifying the task entry and the agent entry. 
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ABSTRACT 

A system and method for blending tasks received from a plurality of 
media switches. The method comprises receiving a plurality of task data 
indicating a plurality of tasks and a plurality of agent data indicating a plurality of 
5 agents. The task data and the agent data are stored in a database system.Tasks are 

assigned to the agents according to workflows. The system comprises a blending 
engine coupled to a plurality of media switches and a plurality of agent 
workstations coupled to the blending engine. The blending engine receives a 
plurality of task data from the media switches. The agent workstations provide a 
10 plurality of agent data to the blending engine. The blending engine provides a 

plurality of task assignments to the agent workstations according to workflows. 
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DECLARATION AND POWER OF ATTORNEY FOR PATENT APPLICATION 
As a below named Inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below, next to my name. 

I believe I am the original, first, and sole inventor (if only one name is listed below) or an original, first, 
and joint inventor (if plural names are listed below) of the subject matter which is claimed and for 
which a patent is sought on the invention entitled 

SYSTEM AND METHOD FOR AUTOMATED AND CUSTOMIZABLE AGENT AVAILABILITY AND 
TASK ASSIGNMENT MANAGEMENT 

the specification of which 

XXX is attached hereto. 

was filed on as 

United States Application Number 

or PCT International Application Number 

and was amended on . 

(if applicable) 

I hereby state that I have reviewed and understand the contents of the above-identified 
specification, including the c!aim(s), as amended by any amendment referred to above. I do not 
know and do not believe that the claimed invention was ever known or used in the United States of 
America before my invention thereof, or patented or described in any printed publication in any 
country before my invention thereof or more than one year prior to this application, that the same 
was not in public use or on sale in the United States of America more than one year prior to this 
application, and that the invention has not been patented or made the subject of an inventor's 
certificate issued before the date of this application in any country foreign to the United States of 
America on an application filed by me or my legal representatives or assigns more than twelve 
months (for a utility patent application) or six months (for a design patent application) prior to this 
application. 

I acknowledge the duty to disclose all information known to me to be material to patentability as 
defined in Title 37, Code of Federal Regulations, Section 1.56. 

I hereby claim foreign priority benefits under Title 35, United States Code, Section 1 1 9(a)-(d), of any 
foreign application (s) for patent or inventor's certificate listed below and have also identified below 
any foreign application for patent or inventor's certificate having a filing date before that of the 
application on which priority is claimed: 
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Priority 

Prior Foreign Application (s) Claimed 



(Number) 


(Country) 


(Day/Month/Year Filed) 


Yes 


No 


(Number) 


(Country) 


(Day/Month/Year Filed) 


Yes 


No" 


(Number) 


(Country) 


(Day/Month/Year Filed) 


Yes" 


No" 



I hereby claim the benefit under title 35, United States Code, Section 1 19(e) of any United States 
provisional application(s) listed below: 



(Application Number) 



(Application Number) Filing Date 

I hereby claim the benefit under Title 35, United States Code, Section 120 of any United States 
application(s) listed below and, insofar as the subject matter of each of the claims of this application 
is not disclosed in the prior United States application in the manner provided by the first paragraph 
of Title 35, United States Code, Section 112, 1 acknowledge the duty to disclose all information 
known to me to be material to patentability as defined in Title 37, Code of Federal Regulations, 
Section 1 .56 which became available between the filing date of the prior application and the national 
or PCT international filing date of this application: 



(Application Number) Filing Date (Status -- patented, 

pending, abandoned) 



(Application Number) Filing Date (Status -- patented, 

pending, abandoned) 

I hereby appoint the persons listed on Appendix A her(5to (which is incorporated by reference and a 
part of this document) as my respective patent attorneys and patent agents, with full power of 
substitution and revocation, to prosecute this application and to transact all business in the Patent 
and Trademark Office connected herewith. 

Send correspondence to: 

Thomas M. Coester, Esq. 
BLAKELY, SOKOLOFF, TAYLOR & ZAFMAN LLP 
12400 Wilshire Boulevard 7th Floor 
Los Angeles, California 90025 

and direct telephone calls to: 

Mark A. Goldstein, (310) 207-3800. 
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I hereby declare that all statements made herein of my own knowledge are 
true and that all statements made on information and belief are believed to 
be true; and further that these statements were made with the knowledge 
that willful false statements and the like so made are punishable by fine or 
imprisonment, or both, under Section 1001 of Title 18 of the United States 
Code and that such willful false statements may jeopardize the validity of 
the application or any patent issued thereon. 

Full Name of Sole/First Inventor Robert H. Jovce 



Inventor's Signature ^t^l^ ff-. Ijo^JL Date ^/yydL 

Residence San Jose. California Citizenship USA 

(City, State) (Country) 

Post Office Address 5814 Avigon Court 

San Jose. California 95138 USA 

Full Name of Second/Joint Inventor Munisekara n Madhipatia 

inventor's Signature . \v-J(^ -^^^^^ ■ Date ^A,, 



Santa Clara. California Citizenship India 



(City, State) (Country) 



Post Office Address 3651 Buckley Street. #801 



Santa Clara. California 95051 USA 



Full Name of Third/Joint Inventor Allan Micha el Moore 

Inventor's Signature Date 



Residence North Vancouver. B.C. Citizenship Canada 



(City, State) (Country) 



Post Office Address 3178 Canfield Crescent 



North Vancouver. B.C. V7R 2V8 CANADA 



Full Name of Fourth/Joint Inventor ^ ✓^•^^^^ick A. Perotti 

Inventor's Signature Date Jv/v^^ j ^C}O0 



Residence Moroan Hill. California Citizenship USA 



(City, State) (Country) 



Post Office Address 505 Calle Siena 



Morgan Hill. California 95037 
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true and that all statements made on Information and belief are believed to 
be true; and further that these statements were made with the knowledge 
that willful false statements and the like so made are punishable by fine or 
imprisonment, or both, under Section 1001 of Title 18 of the United States 
Code and that such willful false statements may jeopardize the validity of 
the application or any patent Issued thereon. 

Full Name of Sole/First Inventor Robert H. Joyce 

Inventor's Signature Date 

Residence San Jose. California Citizenship USA 

(City, State) (Country) 

Post Office Address 5814 Aviaon Court 

San Jose. California 95138 USA 



Full Name of Second/Joint Inventor Munisekaran Madhipatia 

Inventor's Signature Date 

Residence Santa Clara. California Citizenship India 

(City, State) (Country) 

Post Office Address 3651 Bucklev Street. #801 

Santa Clara. California 95051 USA 



Full Name of Third/Joint Inventor Allan IVIIchael mioore 

Inventor's Signature f'Y f^^^^^^- DateKf.^^ t.O^ /U>cx:> 

Residence North Vancouver. B.C. Citizenship Canada 



(City, State) (Country) 



Post Office Address 3178 Canfleld Crescent 



North Vancouver. B.C. V7R 2V8 CANADA 



Full Name of Fourth/Joint Inventor Rick A. Perotti 

Inventor's Signature Date 

Residence Morgan Hill. California Citizenship USA 

(City, State) (Country) 

Post Office Address 505 Calle Siena 

Morgan Hill. California 95037 
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William E. Alford, Reg. No. 37,764; Farzad E. Amini, Reg. No. P42,261 ; Aloysius T. C. AuYeung, Reg. No. 
35,432; William Thomas Babbitt, Reg. No. 39,591; Carol F. Barry, Reg. No. 41,600; Jordan Michael 
Becker, Reg. No. 39,602; Bradley J. Bereznak, Reg. No. 33,474; Michael A. Bemadicou, Reg. No. 
35,934; Roger W. Blakely, Jr., Reg. No. 25,831; Gregory D. Caldwell, Reg. No. 39,926; Ronald C. Card, 
Reg. No. 44,587; Andrew C. Chen, Reg. No. 43,544; Thomas M. Coester, Reg. No. 39,637; Alin Corie, 
Reg. No. P46,244; Dennis M. deGuzman, Reg. No. 41,702; Stephen M. De Klerk, under 37 C.F.R. § 
10.9(b); Michael Anthony DeSanctis, Reg. No. 39,957; Daniel M. De Vos, Reg. No. 37,813; Robert 
Andrew Diehl, Reg. No. 40,992; Sanjeet Dutta, Reg. No. P46,145; Matthew C. Fagan, Reg. No. 37,542; 
TarekN, Fahmi, Reg. No. 41,402; Paramita Ghosh, Reg. No. 42,806; James Y. Go, Reg. No. 40,621; 
James A. Henry, Reg. No. 41,064; Willmore F. Holbrow III, Reg. No. P41,845; Sheryl Sue Holloway, Reg. 
No. 37,850; George W Hoover II, Reg. No. 32,992; Eric S. Hyman, Reg. No. 30,139; William W. Kidd, 
Reg. No. 31 ,772; Sang Hui Kim, Reg. No. 40,450; Eric T. King, Reg. No. 44,188; Erica W. Kuo, Reg. No. 
42,775; Kurt P. Leyendecker, Reg. No. 42,799; Michael J. Mallie, Reg. No. 36,591; Andre L. Marais, 
under 37 C.F.R. § 10.9(b); Paul A. Mendonsa, Reg. No. 42,879; Darren J. Milliken, Reg. 42,004; Lisa A. 
Norris, Reg. No. 44,976; Chun M. Ng, Reg. No. 36,878; Thien T. Nguyen, Reg. No. 43,835; Thinh V. 
Nguyen, Reg. No. 42,034; Dennis A. Nicholls, Reg. No. 42,036; Daniel E. Ovanezian, Reg. No. 41,236; 
Marina Portnova, Reg. No. P45,750; Babak Redjaian, Reg. No. 42,096; William F. Ryann, Reg. 44,313; 
James H. Salter, Reg. No. 35,668; William W. Schaal, Reg. No. 39,018; James C. Scheller, Reg. No. 
31,195; Jeffrey Sam Smith, Reg. No. 39,377; Maria McCormack Sobrino, Reg. No. 31,639; Stanley W. 
Sokoloff, Reg. No. 25,128; Judith A. Szepesi, Reg. No. 39,393; Vincent P. Tassinari, Reg. No. 42,179; 
Edwin H. Taylor, Reg. No. 25,129; John F. Travis, Reg. No. 43,203; George G. C. Tseng, Reg. No. 
41,355; Joseph A. Twarowski, Reg. No. 42,191; Lester J. Vincent, Reg. No. 31,460; Glenn E. Von 
Tersch, Reg. No. 41,364; John Patrick Ward, Reg. No. 40,216; Mark L. Watson, Reg. No. P46,322; 
Thomas C. Webster, Reg. No. P46,154; Kirk D. Williams, Reg. No. 42,229; James M. Wu, Reg. No. 
45,241; Steven D. Yates, Reg. No. 42,242; and Norman Zafman, Reg. No. 26,250; my patent attorneys, 
and Justin M. Dillon, Reg. No. 42,486; my patent agent, of BLAKELY, SOKOLOFF, TAYLOR & ZAFMAN 
LLP, with offices located at 12400 Wilshire Boulevard, 7th Floor, Los Angeles, California 90025, 
telephone (310) 207-3800, and Mark J. Meltzer, Reg. no. 28,739 of ASPECT COMMUNICATIONS, with 
offices located at 1310 Ridder Park Drive, San Jose, California 95131, and James R. Thein, Reg. No. 
31,710, my patent attorney. 
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APPENDIX B 



Title 37, Code of Federal Regulations, Section 1 .56 
Duty to Disclose Information Material to Patentability 

{a) A patent by its very nature is affected with a public interest. The public interest is best served, 
and the most effective patent examination occurs when, at the time an application is being examined, the 
Office is aware of and evaluates the teachings of all information material to patentability. Each individual 
associated with the filing and prosecution of a patent application has a duty of candor and good faith in dealing 
with the Office, which includes a duty to disclose to the Office all information known to that individual to be 
material to patentability as defined in this section. The duty to disclosure Information exists with respect to 
each pending claim until the claim is cancelled or withdrawn from consideration, or the application becomes 
abandoned. Information material to the patentability of a claim that is cancelled or withdrawn from 
consideration need not be submitted if the information is not material to the patentability of any claim remaining 
under consideration in the application. There is no duty to submit information which is not material to the 
patentability of any existing claim. The duty to disclosure all information l<nown to be material to patentability 
is deemed to be satisfied if all information known to be material to patentability of any claim issued in a patent 
was cited by the Office or submitted to the Office in the manner prescribed by §§1 .97(b)-(d) and 1 .98. 
However, no patent will be granted on an application in connection with which fraud on the Office was practiced 
or attempted or the duty of disclosure was violated through bad faith or intentional misconduct. The Office 
encourages applicants to carefully examine: 

(1 ) Prior art cited in search reports of a foreign patent office in a counterpart application, and 

(2) The closest information over which individuals associated with the filing or prosecution of a 
patent application believe any pending claim patentably defines, to make sure that any material information 
contained therein is disclosed to the Office. 

(b) Under this section, information is material to patentability when it is not cumulative to 
information already of record or being made or record in the application, and 

(1) It establishes, by itself or in combination with other information, a prima facie case of 
unpatentability of a claim; or 

(2) It refutes, or is inconsistent with, a position the applicant takes in: 

(i) Opposing an argument of unpatentability relied on by the Office, or 

(ii) Asserting an argument of patentability. 

A prima facie case of unpatentability is established when the information compels a conclusion that a claim is 
unpatentable under the preponderance of evidence, burden-of-proof standard, giving each term in the claim its 
broadest reasonable construction consistent with the specification, and before any consideration is given to 
evidence which may be submitted in an attempt to establish a contrary conclusion of patentability. 

(c) Individuals associated with the filing or prosecution of a patent application within the 
meaning of this section are; 

(1) Each inventor named in the application; 

(2) Each attorney or agent who prepares or prosecutes the application; and 

(3) Every other person who is substantively involved in the preparation or prosecution of the 
application and who is associated with the inventor, with the assignee or with anyone to whom there is an 
obligation to assign the application. 

(d) Individuals other than the attorney, agent or inventor may comply with this section by 
disclosing information to the attorney, agent, or inventor. 
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